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SYSTEM AND METHOD FOR A 
MULTI-APPLICATION SMART CARD 
WHICH CAN FACILITATE A POST- 
ISSUANCE DOWNLOAD OF AN 
APPLICATION ONTO THE SMART CARD 

CROSS REFERENCE TO RELATED 
APPLICATION 

This application claims priority to U.S. provisional appli- 
cation No. 60/061,763 filed Oct. 14, 1997, which is herein 
incorporated by reference. This application further claims 
priority to U.S. provisional application No. 60/041,468 filed 
Mar. 24, 1997, which is also herein incorporated by refer- 
ence. 

This application is related to U.S. application Ser. No. 
09/046,993 now U.S. Pat. No. 6,005,942 (VISAP009 or 
VISAP010), filed on even date herewith which is also herein 
incorporated by reference for all purposes. 

FIELD OF THE INVENTION 

The present invention relates to smart cards. In particular, 
the present invention relates to a system and method for 
providing a multi-application smart card which can facilitate 
a post- issuance download of an application onto the smart 
card. 

BACKGROUND OF THE INVENTION 

A smart card is typically a credit card-sized plastic card 
that includes a semiconductor chip capable of holding data 
supporting multiple applications. 

Physically, a smart card often resembles a traditional 
"credit" card having one or more semiconductor devices 
attached to a module embedded in the card, providing 
contacts to the outside world. The card can interface with a 
point-of-sale terminal, an ATM, or a card reader integrated 
into a telephone, a computer, a vending machine, or any 
other appliance. 

A micro -controller semiconductor device embedded in a 
"processor" smart card allows the card to undertake a range 
of computational operations, protected storage, encryption 
and decision making. Such a micro-controller typically 
includes a microprocessor, memory, and other functional 
hardware elements. Various types of cards are described in 
"The Advanced Card Report: Smart Card Primer", Kenneth 
R. Ayer and Joseph F. Schuler, The Schuler Consultancy, 
1993. 

One example of a smart card implemented as a processor 
card is illustrated in FIG. 1. Of course, a smart card may be 
implemented in many ways, and need not necessarily 
include a microprocessor or other features. The smart card 
may be programmed with various types of functionality, 
including applications such as stored-value; credit/debit; 
loyalty programs, etc. 

In some embodiments, smart card 5 has an embedded 
micro-controller 10 that includes a microprocessor 12, ran- 
dom access memory (RAM) 14, read-only memory (ROM) 
16, non-volatile memory 18, a cryptographic module 22, and 
a card reader interface 24. Other features of the micro- 
controller may be present but are not shown, such as a clock, 
a random number generator, interrupt control, control logic, 
a charge pump, power connections, and interface contacts 
that allow the card to communicate with the outside world. 

Microprocessor 12 is any suitable central processing unit 
for executing commands and controlling the device. RAM 
14 serves as storage for calculated results and as stack 
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memory. ROM 16 stores the operating system, fixed data, 
standard routines, and look up tables. Non-volatile memory 
18 (such as EPROM or EEPROM) serves to store informa- 
tion that must not be lost when the card is disconnected from 

5 a power source but that must also be alterable to accommo- 
date data specific to individual cards or any changes possible 
over the card lifetime. This information might include a card 
identification number, a personal identification number, 
authorization levels, cash balances, credit limits, etc. Cryp- 

10 tographic module 22 is an optional hardware module used 
for performing a variety of crptographic algorithms. Card 
reader interface 24 includes the software and hardware 
necessary for communication with the outside world. A wide 
variety of interfaces are possible. By way of example, 

15 interface 24 may provide a contact interface, a close-coupled 
interface, a remote-coupled interface, or a variety of other 
interfaces. With a contact interface, signals from the micro- 
controller are routed to a number of metal contacts on the 
outside of the card which come in physical contact with 

20 similar contacts of a card reader device. 

Various mechanical and electrical characteristics of smart 
card 5 and aspects of its interaction with a card reading 
device are defined by the following specifications, all of 
which are herein incorporated by reference. 

25 Visa Integrated Circuit Card Specification, (Visa Interna- 
tional Service Association 1996). 

EMV Integrated Circuit Card Specification for Payment 
Systems, (Visa International Service Association 1996). 

3Q EMV Integrated Circuit Card Terminal Specification for 
Payment Systems, (Visa International Service Association 
1996). 

EMV Integrated Circuit Card Application Specification 
for Payment Systems, (Visa International Service Associa- 

35 tion 1996). 

International Standard; Identification Cards — Integrated 
Circuits) Cards with Contacts, Parts 1-6 (International 
Standards Organization 1987-1995). 
Prior to issuance of a smart card to a card user, the smart 

40 card is initialized such that some data is placed in the card. 
For example, during initialization, the smart card may be 
loaded with at least one application, such as credit or stored 
cash value, a file structure initialized with default values, 
and some initial cryptographic keys for transport security. 

45 Once a card is initialized, it is typically personalized. During 
personalization, the smart card is loaded with data which 
uniquely identifies the card. For example, the personaliza- 
tion data can include a maximum value of the card, a 
personal identification number (PIN), the currency in which 

50 the card is valid, the expiration date of the card, and 
cryptographic keys for the card. 

A limitation of conventional smart cards is that new 
applications typically can not be added to an issued smart 
card. Smart cards are traditionally issued with one or more 

55 applications predefined and installed during the manufac- 
turing process of the card. As a result, with traditional smart 
card implementation, once a card has been issued to a card 
user, the smart card becomes a fixed application card. If a 
new application is desired, the smart card is typically 

60 discarded and a new smart card, which includes the new 
application, is issued. 

It would be desirable to provide a smart card which would 
allow applications to be loaded after the card is issued. 
Further, it is desirable to provide a mechanism to manage the 

65 loading of an application as well as general management of 
the applications on the smart card. Additionally, it is desir- 
able to allow an application provider to keep cryptographic 
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keys confidential from the issuer of the smart card and to FIGS. 3A-3B are block diagrams of examples of software 

securely allow application from different entities to coexist layers according to embodiments of the present invention, 

on a card. FIG. 4 is a flow diagram of an example of a method 

SUMMARY OF THE INVENTION 5 f* 0 ^ 10 an l em |*> dim <f ° f ,he P resen ' invention for 

5 installing an application onto an issued smart card utilizing 

Embodiments of the present invention teach a system and a card domain, 

method which allows card issuers to add applications during FIG. 5 is a flow diagram of a method according to an 

the lifetime of the card after the card has already been issued embodiment of the present invention for providing confi- 

(referred to herein as post issuance loading). The process of dential information to an application in a smart card using 

downloading an application after the card has been issued to 10 security domains. 

the card holder will be referred to herein as a "secure install" FIG. 6 is a flow diagram of an example of a method 

process. according to an embodiment of the present invention for 

The system and method according to embodiments of the installing an application onto an issued smart card utilizing 

present invention allow the loading of an application and/or a card domain. 

objects from an application server via a card acceptance " FIG. 7A is a flow diagram illustrating a sequence of card 

device and its supporting system infrastructure delivery jjf e states 

mechanism, onto a card, post issuance in a secure and rir . a ,. .« . c , 

c , ; r FIG. 7B is a flow diagram illustrating a sequence of card 

confidential manner. rr ° & n 

lite states. 

An embodiment of the present invention provides a „ Tr , 0 . .« . e , - , 

, j tU j- .£ cj i • r * 20 FIG. 8 is an illustration of an example of a card life cycle, 

system and method for providing confidential information to n . r , - , , 

an application in a smart card. In a multi- application smart mG ' 9 15 a flow diagram of an example of a method 

card, a privileged application, herein referred to as a security "x™*W to an embodiment of the present invention for 

domain, is utilized as a confidential representative of an blockm S a card uUhzm S a card domain - 

application provider. The security domain can contain cryp- FIG - 10 is a block diagram illustrating interactions 

tographic keys which can be kept confidential from the 25 between a card domain and a security domain on a smart 

smart card issuer, thus allowing separation of cryptographic card according to an embodiment of the present invention, 

security between the issuer and the application provider. FIGS. HA and 11B are flow diagrams of an example of 

When a new application is loaded onto a smart card, the a method according to an embodiment of the present inven- 

newly loaded application can utilize its associated security tion for loading an application by using a security domain 

domain's cryptographic service. A privileged application 30 after the smart card has issued. 

representing the issuer, herein referred to as a card domain, FIGS. 12A-12B are flow diagrams of an example of a 

can approve of commands, such as commands for initial- method according to an alternate embodiment of the present 

ization and personalization, by invoking the security invention for loading an application using a security domain 

domain's cryptographic service. In this manner, a post after the smart card has issued. 

issuance download of an application onto the issued smart 35 FIG. 13 is a block diagram illustrating an example of key 

card can be accomplished. management and key dependencies for post issuance down- 

A method according to an embodiment of the present load of applications onto the smart card, 
invention for providing confidential information to an appli- 
cation in a smart card is presented. The method comprises DETAILED DESCRIPTION OF THE 
the steps of providing a first application in the smart card, the PREFERRED EMBODIMENTS 
first application including a cryptographic service; loading a The following description is presented to enable one of 
second application onto the smart card; and installing the ordinary skill in the art to make and to use the invention and 
second application, wherein the cryptographic service of the is provided in the context of a patent application and its 
first application is utilized to install the second application. 45 requirements. Various modifications to the preferred 

In another aspect of the invention, a system according to embodiments will be readily apparent to those skilled in the 

an embodiment of the present invention for providing con- art and the generic principles herein may be applied to other 

fidential information to an application in a smart card is embodiments. Thus, the present invention is not intended to 

presented. The system comprises a first application associ- be limited to the embodiment shown but is to be accorded 

ated with the issued smart card, wherein the first application 50 the widest scope consistent with the principles and features 

includes cryptographic service; and a second application described herein. 

associated with the issued smart card, the second application FIG. 2 is a block diagram of an example of software layers 
being in communication with the first application, wherein which can be utilized in a smart card. The smart card shown 
the cryptographic service included in the first application is m FIG. 2 includes an operating system 200, a card applica- 
utilized for at least one function related to the second ss UO n programming interface (API) 204, and applications 
application. In yet another aspect of the invention, a method 206A-206B. Operating system 200 can include functional- 
according to an embodiment of the present invention for ity to control the cards, memory management, input/output 
providing an application to a smart card is presented. The QjQ) f and cryptographic features. Card API 204 utilizes the 
method comprising the steps of issuing a smart card; loading instructions from operating system 200 and writes these 
a first application onto the issued smart card; and initializing 60 instructions into blocks which can be reused for common 
the first application. routines in multiple applications. Applications 206A and 

DnfCC nr^oninTinxT r^r xnr nn a^wtxt^o 206B can run on the smart card via instructions from API 

BRIEF DESCRIPTION OF THE DRAWINGS « r • i j r l- L 

204. lnese applications can include any application which 

FIG. 1 is a block diagram of a smart card system suitable can run on a smart card, such as stored value, credit, debit, 

for implementing the present invention. 65 transit, and loyalty. 

FIG. 2 is an example of a block diagram of so ft ware layers One embodiment of the present invention is based upon 

which can be utilized in a smart card. the Java Card standard. In this case applications are referred 
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to as 'Applets' and they are written to link to a Java Card API 
which is the application programming interface present on 
smart cards built to the Java Card standard. 

Although the conventional software system shown in 
FIG. 2 allows for multiple applications, it does not solve the 
problem of how to load, securely, an application after 
issuance of the smart card to a user. If an application is to be 
loaded post issuance, a mechanism is needed to manage the 
loading of an application as well as general management of 
the applications on the smart card. Additionally, an appli- 
cation provider may wish to keep cryptographic keys con- 
fidential from the issuer of the smart card. Accordingly, a 
mechanism is needed to provide for the separation of 
confidential information between an application provider 
and an issuer of a smart card. Embodiments of the present 
invention address such a need. 

FIGS. 3A-3B are block diagrams showing software com- 
ponents of a smart card according to embodiments of the 
present invention. The arrows indicate dependencies 
between components. FIG. 3A shows an embodiment of a 
smart card utilizing a card domain, while FIG. 3B shows an 
embodiment of a smart card utilizing a security domain, as 
well as a card domain. 

The example shown in FIG. 3 A includes an operating 
system 300, a card API 304, applications 305A-305C, a card 
domain 308, and open platform (OP) API 306. The system 
shown in FIG. 3 allows for a secure and managed post 
issuance download of an application onto a smart card. 

Open platform API 306 classifies instructions into card 
domain 308 and security domains 310A-310B (shown in 
FIG. 3B). Accordingly, OP API 306 facilitates the formation 
of instructions into sets which can be identified as being 
included as part of card domain 308 and security domains 
310A-310B. 

Applications 305A-305C can include any application 
which can be supported by a smart card. Examples of these 
applications include credit, debit, stored value, transit, and 
loyalty. Applications 305A-305C are shown to include 
command interfaces, such as APDU interfaces 354A-354C 
which facilitate communication with the external environ- 
ment. 

Applications 305Aand 305B can run on the smart card via 
instructions from card API 304. Card API 304 is imple- 
mented using the instructions from the card operating sys- 
tem and writes these instructions into blocks which can be 
reused for common routines for multiple applications. Those 
skilled in the art will recognize that a translation layer or 
interpreter may reside between API 304 and operating 
system 300. An interpreter interprets the diverse hardware 
chip instructions from vendor specific operating system 300 
into a form which can be readily utilized by card API 304. 

Card domain 308 can be a- "privileged" application which 
represents the interests of the smart card issuer. As a 
"privileged" application, card domain 308 may be config- 
ured to perform multiple functions to manage various 
aspects of the smart card. For instance, card domain 308 can 
perform functions such as installing an application on the 
smart card, imtalling security domain s 310A-310B (shown 
on FIG. 3B), personalization and reading of card global data, 
managing card life cycle states (including card blocking), 
performing auditing of a blocked card, maintaining a map- 
ping of card applications 305A-305C to security domains 
310A-310B, and performing security domain functions for 
applications 305A-305C which are not associated with a 
security domain 310. 

Card domain 308 is shown to include an API interface 350 
and a command interface, such as Application Protocol Data 
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Unit (APDU) interface 352. APDU interface 352 facilitates 
interfacing with the external environment. In compliance 
with, e.g., International Standards Organization (ISO) Stan- 
dard 7816-4, entitled "Identification Cards — Integrated 
5 circuits) cards with contacts — Part 4, Inter-industry com- 
mands for interchange," which is herein incorporated by 
reference. 

For example, APDU interface 352 can be used during post 
issuance installation of an application or during loading of 

10 card global data. An application load and install option is 
performed via a set of appropriate APDU commands 
received by card domain 308. API interface 350 facilitates 
interfacing with the internal smart card environment. For 
example, API interface 350 can by used if card domain 308 

15 is being utilized as a default in place of a security domain 
310, or if an application requires information such as card 
global data, key derivation data, or information regarding 
card life cycle. 

Memory allocations have been performed by the time an 

20 application is in an install state. An application is also 
personalized after loading and installing. A personalized 
application includes card holder specific data and other 
required data which allows the application to run. In addition 
to managing the installation and personalization of the 

25 application, card domain 308 can also manage global card 
information. Global card information includes information 
that several applications may need to perform their 
functions, such as card holder name and card unique data 
utilized in cryptographic key derivations. Card domain 308 

30 can be a repository for the global card information to avoid 
storing the same data multiple times. 

Card domain 308 can also manage card life cycle states 
including card blocking. The smart card will typically move 

35 through several states during its life cycle. Card domain 308 
keeps track of what state the card is in during its life cycle. 
Card domain 308 may also manage a block request to block 
virtually all functions of the card. Further details of card 
domain 308 management of a block request will be dis- 

^ cussed in conjunction with FIG. 6. Card domain 308 may 
also keep track of the state of an application during an 
application's life cycle. This kind of information regarding 
an application can be utilized during an auditing of a card. 
Auditing can be performed at any time during a card's 

4S lifetime. For instance, auditing may be performed after a 
card has been blocked or prior to installing a new application 
to validate the card contents. Although virtually all card 
functions are no longer functioning when a card is blocked, 
an issuer may be able to query card domain 308 for 

5Q information regarding a state of an application or the life 
cycle state of the card. In this manner, the issuer of a card 
may still access a profile of the blocked card and its 
applications. 

FIG. 3B shows an embodiment of the present invention 
55 utilizing a security domain 310, as well as card domain 308. 
The example shown in FIG. 3B includes a operating system 
300', a card API 304', applications 305A-305C, security 
domains 310A-310B 1 , a card domain 308', and open plat- 
form (OP) API 306'. The system shown in FIG. 3B also 
so allows for a secure and managed post issuance download of 
an application onto a smart card. 

Card domain 308' can work in conjunction with a security 
domain 310. Security domain 310 is a logical construct that 
can be implemented as an application to provide security 
65 related functions to card domain 308* and to applications 
associated with security domain 310. Security domains 
310A-310B can assist in secure post issuance loading of an 
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application onto the smart card. Security domains 
310A-310B provide for a mechanism which keeps the 
application provider's confidential information, such as 
cryptographic keys, from being disclosed to the issuer of the 
smart card. 

There may be multiple security domains 310 on a smart 
card, each represented by a unique cryptographic relation- 
ship. A security domain 310 is responsible for the manage- 
ment and sharing of cryptographic keys and the associated 
cryptographic methods which make up the security 
domain's cryptographic relationship. An application which 
is loaded to the smart card post issuance can be associated 
with a security domain, preferably with only one security 
domain. However, multiple applications may be associated 
with the same security domain 310. Applications installed 
on a smart card during the pre-issuance phase may option- 
ally be associated with a security domain 310 on the smart 
card for purposes of loading confidential personalization 
data to those applications using security domain 310 keys. 

The software for security domain 310 may be installed by 
the card manufacturer at the time of card manufacturing 
(e.g., when the ROM is masked), or may be added during 
initialization or personalization stages. Security domains 
310 can be implemented as selectable applications which are 
isolated from one another and the rest of the system. If 
security domain 310 is implemented in a Java card as an 
application, standard Java card security can be relied upon 
to ensure isolation of security domain 310. In addition, or 
alternatively, other security mechanisms such as hardware 
security which can be utilized through OP API 306 imple- 
mentation. OP API 306 may utilize special security features 
to enforce isolation of security domain 310. An example of 
such a security feature is the utilization of chip hardware 
security routines which may be employed by OP API 306. 

Each security domain 310A-310B provides a command 
interface, such as an Application Protocol Data Unit 
(APDU) interface 320A-320B, for communication off card 
and an on card API interface 322A-322B. 

The APDU interface 320A-320B consists of personaliza- 
tion commands and is intended to allow the initial loading of 
security domain keys and to support key rotation if desired 
during the life of the security domain. API interfaces 
322A-322B may include a signature verification method 
and decryption method which are shared with card domain 
308' for post issuance loading of applications. Additionally, 
applications may utilize API interfaces 322A-322B for 
decrypting application confidential data. Note that card 
domain 308' may always function as a security domain and 
does so as the default. 

Security domain 310 manages signing and decrypting 
keys and provides cryptographic services using those keys. 
Security domain 310 processes APDU's for numerous func- 
tions. These functions can include key management func- 
tions e.g., functions to load or update keys. During Secure 
Installation of an application, security domain 310 can 
provide services to card domain 308' to decrypt an applica- 
tion install file and check the signature of an application file. 
For an application associated with a security domain 310, 
that application's security domain 310 provides decrypt and 
signature functions, such as MACing on an update key 
APDU command during the personalization phase of a 
newly installed application. Thereafter, the application can 
use the updated key to decrypt and check signatures on 
subsequent key updates. 

The smart card issuer may decide whether security 
domain 310 utilizes a static key or a session key for 
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transactions. Astatic key is a cryptographic key which exists 
prior to processing APDUs and which exist during and after 
the processing of APDUs, A session key is a cryptographic 
key which can be generated for a particular transaction and 
5 is typically no longer used for APDU processing after the 
transaction. If a session key is utilized, security domain 310 
preferably derives its own session key for processing 
APDUs. 

FIG. 4 is a flow diagram of a method accordingly to an 

10 embodiment of the present invention for providing an appli- 
cation onto a smart card. The example illustrated in FIG. 4 
also applies to installing a security domain 310 onto a smart 
card. Note that all of the flow diagrams in this application are 
merely examples. Accordingly, the illustrated steps of this 

15 and any other flow diagram herein, can occur in various 
orders and in varying manners in order to accomplish 
virtually the same goal. 

A smart card is issued (step 400), and an application is 
forwarded to the issued smart card (step 402), The forward- 

20 ing of the application can occur through any electronic 
media which can interface with a smart card and connect to 
an appropriate network. For example, devices such as an 
automatic teller machine (ATM), a display phone, or a home 
computer, can be used to forward an application to the issued 

25 smart card. The forwarded application is then loaded onto 
the smart card, wherein the loading of the application is 
managed by card domain 308 (step 404). 
FIG. 5 is another flow diagram of a method according to 

30 an embodiment of the present invention for providing an 
application onto an issued smart card. A smart card is created 
and provided with a first application, the first application 
including a cryptographic service (step 1002). A second 
application is loaded onto the smart card (step 1004). 

35 Thereafter, the second application is installed, wherein the 
cryptographic service of the first application is utilized to 
install the second application (step 1006). 

FIG. 6 is another flow diagram of an example of a method 
according to an embodiment of the present invention for 

40 providing an application onto an issued smart card. This 
method for providing an application also applies to provid- 
ing a security domain 310 onto the smart card. In the 
example shown in FIG. 6, a card issuer deploys smart cards 
to customers (step 500). A decision is made to install vendor 

45 A's application onto the issued smart card (step 502). When 
a dialogue between the issuer and the smart card is initiated, 
aj3re-s2gnea^^py_oiLm 

smart card (step 504)., As previously stated, the dialogue 
between the" issuer and the smart card can occur via any 

50 electronic device which can interface with a smart card and 
connect to an appropriate network. The application can be 
pre-signed with a key equivalent to that which already exists 
on the card so that each application has a unique signature 
that can be verified by the card. 

55 Card domain 308 can then take the steps to load the 
application. Card domain 308 decrypts the forwarded appli- 
cation and checks the signature of the application (step 508). 
Card domain 308 can decrypt the application with the 
issuer's secret key. An appropriate cryptography method, 

60 such as Data Encryption Standard (DES) or 3DES, can be 
utilized to decrypt at least a portion of the application. Those 
skilled in the art will recognize that a number of crypto- 
graphic techniques may be used to implement embodiments 
of the present invention. For the purpose of illustration, 

65 symmetric key techniques are addressed herein, although 
asymmetric techniques are also contemplated. A good gen- 
eral cryptography reference is Schneier, Applied 
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Cryptography, 2d Ed. (John Wiley, 1996), the contents of states. Each application is preferably responsible for its own 

which are incorporated herein by reference. application life cycle state management but it preferably 

■s It is then determined whether the signature on the appli- allows card domain 308 to have access to its life cycle states 

cation is valid (step 510). If the signature associated with the for auditing purposes. 

application is not valid, then the application is not loaded 5 The Card Life cycle is designed in such a way to increase 

onto the card and the process ends (step 520). If, however, ^ level of securitv enforced by the card at each successive 

the signature associated with the application is valid the state " M f l ^ d abov f> »he cycle is also established as a 

application is then installed and available for personaliza- P^ss which can only ratchet forward to ensure that once 

^ . „ i- r *u 1* *• * the card begins a lite cycle state with associated security 

tion. During personalization the application receives person- olicies the onl o tion is to c cle forward to the next state 

alization data (step 512). Personalization data includes data 10 r : l • u i i c ■* m. o j 

.... • 5 iL - „ . in the life cycle with a higher level of security. The Card 

which is unique to the smart card user. For instance, in a Domain as ^ ^ securit m f of the card main . 

airline loyalty application, personalization data can include taiflS tQe currem m& cyde enforces the associated 

the smart card user's seating preference, meal preference, security policies, and controls the state transitions in the 

and eligibility for various possible perks. This personaliza- c ar cl life cycle. 

tion data can also be signed and encrypted. 15 HG ?fi ^ a flow diagram illustrating an example of a 

The application then invokes card domain's 308 decryp- sequence of an application life cycle. The application is 

tion service (step 513). Card domain 308 can then performs initially unavailable (step 750). The next state is a loaded 

a signature check (step 514). Methods of decrypting per- state (step 752). The application reaches the loaded state 

sonalization data and performing signature checks are well once the application has been loaded onto the smart card, 

known in the art. Finally, the application can then be 20 The application is then installed (step 754), and registered 

activated (step 518). (step 756). Once the application is registered, it can be 

A new application which as been downloaded onto a iskfei al any time thereafter. The next state is the person-" 

smart card post-issuance can be stored in a variety of ways. a L hzed statc > ^ her 5 m P^j^ed information is included m 

One example is to store the application into a file. Another ^ e •^ U ^ D ^ ( aPphCatl ° n ™ y 

example is to maintain a pointer to the application object. 25 eXp i r ^ °* . 6 °° e : 6p 

^i, „ A . „ .„ . , , FIG. 8 is an illustration of an example of multi-apphcation 

7A * a flow r dia S ram ^ustrating an example of a card 1Lfe time line ^ time Une $tarts ^ a Masked RQM 

sequence of card life states. The sequence is preferably stage 800 and ends with a card blocked/expired stage 802. 

considered irreversible. The first card life state is when the At Maske d ROM stage 800, applications A, B, C and D are 

smart card is Masked (700). During the Masked state (700), 3Q sn0 wn to be installed. This example shows applications A 

the smart card obtains its operating system, card an d b being installed at a masking stage of the card, 

identification, and preferably at least one application. The applications C and D being installed at initialization stage, 

Masked state (700) is achieved as soon as all of the neces- md applications D and F being installed post issuance, 

sary components for card initialization are made available. j n ^ examplej application A can be installed in ROM 

An example of when necessary components are made avail- 35 md used during me com pi ete itf e 0 f the card from Masked 

able is when card domain 308 and OP API 306 are enabled, ROM stage 800 to card blocked/expired stage 802. Appli- 

as well as the Java card environment being enabled, such as cation B is also in ROM and utilized during a first portion 

Java card virtual machine 302 and Java card API 304 (both of lhe life of me smart card ^ m& of ap pU cation B is 

of FIG. 3). ended at stage 804A. Application C is located in non-volatile 

After the Masked state, the next state is the Initialized ^ mem0 ry, such as EEPROM, which is loaded during initial- 

(step 702) state. The Initialized state is achieved once all ization. Application C is shown to expire at stage 804B. 

card activity requiring an initialization key is complete. As Application D is also located in EEPROM and is used for the 

part of card initialization, if not already available, the card complete life of the card until card blocked/expired stage 

domain 308 application must be installed and registered. In 802. Application E is installed at stage 806A, sometime after 

addition, one or more security domains may also be installed 45 is sua nce of the smart card. Application E is located in 

and registered. These installed domains must then be EEPROM and used until the end of the card life at card 

selected and personalized. An initialization key is a secret blocked/expired stage 802. Application F is also installed 

key which is typically used by a smart card manufacturer post issuance at stage 806B, and expires sometime before 

during loading of data onto the smart card prior to issuance. me end of the card life at stage 804C. 

The next state is Load Secured (step 704). Hie Load 50 FIG. 9 is a flow diagram of a method according to an 

Secured state is achieved after a secure install (post-issuance embodiment of the present invention for blocking a card. A 

download) mechanism for loading of applications through car d be can be blocked if a breach of security is detected by 

the remainder of the card lifetime has been established. m application. According to an embodiment of the present 

The final card life state is when the card is either expired invention, a smart card can be blocked while an application 

or blocked (step 706). The blocked state is achieved as soon 55 is in use. A blocked card will no longer operate so that a 

as an authorized smart card application has received a suspect user cannot utilize any of the applications on the 

command to block the card. smart card. Blocking is merely one example of the many 

The card life cycle is preferably an irreversible sequence functions card domain 308 can perform in managing the 

of states with increasing security. Initialization and all other applications on the smart card. Examples of other 

subsequent card life cycle states and their transition are 60 functions include installing an application on the smart card, 

preferably under the control of card domain 308. Card installing security domains 310A-310B, personalization and 

domain 308 executes and responds to commands that result reading of card global data, managing card life cycle states 

in a transition in a card life cycle from one state to the next. including card blocking, performing auditing of a block 

These commands are preferably Application Protocol Data card, maintaining a mapping of card applications to security 

Unit (APDU) commands. Card domain 308 is also respon- 65 domains, and performing security domain functions for 

sible for the installation of applications on the card, but applications which are not associated with a security 

preferably has no control over the applications' life cycle domain. 
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In the example shown in FIG. 9, an application is cur- The smart card's card domain 308 then takes steps to load 
rently in use (step 600). The application detects a problem the application. Card domain 308 invokes an associated 
which triggers a card block request from the application security domain's cryptographic service to decrypt the appli- 
(step 602). The application then sends a card block request cation and check the signature (step 1118). It is then deter- 
to card domain 308 (step 604). Card domain 308 determines 5 mined if the signature is valid (step 1120). If the signature 
whether the card block request is valid (step 606). A card is not valid, the process ends (step 1122). If, however, the 
block request can be valid if the request originates from a signature is found to be valid, then the application receives 
predetermined application. If the card block request is not personalization data which can be signed and optionally 
valid, the card domain 308 does not block the smart card encrypted (step 1124). The loaded application then invokes 
(step 608). However, if the card block request is valid, then its associated security domain's decryption service and 
card domain 808 authorizes the card blocking (step 610), signature check (step 1126). Secret keys required to run or 
and card domain 308 blocks the smart card (step 612) such operate the application on the smart card are used to activate 
that the smart card will reject any attempted transactions for the application by authentication (step 1130). 
any of the applications on the card. FIGS 12A m a 12B are flow diagrams of a method 

FIG. 10 is a block diagram illustrating the use of security according to another embodiment of the present invention 

domain 310 by the card domain 308. The method and system for pr0 viding confidential information to an application 

according to an embodiment of the present invention allows using a scanty domain 310. The issuer decides to include 

for multiple apphcation providers to be represented on a a security domain 310 on a smart card (step 1200). A trusted 

smart card in a secure and confidential manner. This security tes ^ t hic ke V md s J ds the k 

and confidentiality can be achieved through the use of : i- „■ * • ✓/ 

•* j ■ imA hat) * • i ™ to a card personalization agent in a secure manner (step 

security domain 310A-310B shown m FIG. 3. 20 . , * , ^ . 4 . & „ A . . . ^ « r v * 

^ 1A .„ , . , - A , ,. . 1201). A trusted party is typically a third party who performs 

FIG. 10 illustrates an example of a smart card which *u a *• c • H c • * l 

contains two security domains 310A-310B. In this example, me A ° f the source of information, such as 

it is assumed that a masked application 305A from the smart a signature A card persona hzation agent (which may be the 

card is associated with a security domain, such as security same as the trusted ^ receives the ke y and loads a 

domain 310A, and an additional application 305B will be 25 umque secure domam key associated with a specific security 

added post issuance and be associated with a second security domain 310 for each smart card (step 1202). 

domain, such as security domain 310B. The arrows indicate The card personalization agent receives the smart card 

key relationships between the various smart card entities. and collects other data, such as application and card holder 

Masked application 305A uses key services from security specific data, and places the data on the smart card (step 

domain 310A for decrypting confidential data and optionally 30 1204). The issuer then deploys the smart card to its custom- 

for full personalization. Card domain 308 uses key services ers (step 1206). A decision is made to install vendor A's 

from security domain 31 0B for decrypting and checking the application on the issued smart card (step 1208). Vendor A 

signature of an application loaded post issuance, such as post obtains secret keys for security domain 310 from the trusted 

issuance loaded apphcation 305B. Post issuance loaded party (step 1210). Vendor A then sends the smart card issuer 

application 305B uses key services from security domain 35 a signed copy of Vendor A's application (step 1212). 

310B for decrypting confidential data and optionally for full When a dialogue between the smart card issuer and the 

personalization. smart card is initiated, a signed copy of the application is 

FIGS. 11A and 11B are further flow diagrams of an forwarded to the smart card (step 1214). The application can 

example for a method according to an embodiment of the be signed with a key equivalent to that which already exists 

present invention for providing an application onto an issued 40 on the smart card so that each application has a unique 

smart card. The card issuer decides to include a security signature that can be verified by the smart card. Card domain 

domain 310 onto a smart card (step 1100). The issuer assigns 308 invokes security domain's cryptographic service to 

security domain 310 to vendor A (step 1102). Vendor A, or decrypt the associated application and check its signature 

an apphcation developer on behalf of vendor A, generates (step 1218). It is then determined whether the signature is 

cryptographic keys such as those used in symmetric or 45 valid (step 1220). If the signature is not valid, then the 

asymmetric cryptography operations (step 1104). Examples process ends (step 1222). 

of these cryptography operations include encryption, If, however, the signature is valid, then the apphcation 

decryption, MACing, Hashing, and digital signatures. receives personalization data, which can be signed and 

Examples of cryptographic methods which utilize such keys optionally encrypted (step 1224). The loaded application 

and are suitable for implementation for the embodiment of 50 then invokes security domain's decryption service and sig- 

the method and system of the present invention include Data nature check (step 1226). The cryptographic secret data 

Encryption Standard (DES) and 3DES. The card personal- required to run or operate the application on the card are 

ization agent receives the keys and loads security domain used to activate the apphcation (step 1230). 

keys associated with a specific security domain 310 for each FIG. 13 is a block diagram illustrating the use of cryp- 

smart card (1106). The card personalization agent receives 55 tographic keys for post issuance loading of an application 

smart cards and collects other data, such as application and onto a smart card. Applications that are not masked and not 

card holder specific data, and places data on the smart card loaded during card initialization stage or personalization 

(step 1108). stage need their execu tables downloaded using a secure 

The card issuer then deploys the smart card to customers installation method, such as the post issuance download 

(step 1110). A decision is then made to install vendor A*s 60 described in previous Figures. The applications can be 

application on the smart card (step 1112). When a dialogue loaded using the card domain cryptographic keys. The 

between the smart card issuer and the smart card is initiated, applications are then decrypted and can have their signature 

a signed copy of the apphcation is forwarded to the smart verified using the key services of the corresponding security 

card (step 1114). The application can be signed with a key domain 310. Therefore, the desired security domain(s) 310 

equivalent to that which already exists on the smart card so 65 preferably have encryption and signature keys installed prior 

that each apphcation has a unique signature that can be to the post issuance download of the corresponding appli- 

verified by the smart card. cation. 
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In the example shown in FIG. 13, only one security 
domain 310 is shown since security domains 310 for other 
applications are not relevant to illustrate the downloading of 
a single application. Note that the result of the secure 
installation is initially a loaded application, which must then 5 
be installed, registered and personalized. After loading, the 
application is installed, preferably by issuing an install 
APDU command to card domain 308. An application can be 
installed when its install method has executed successfully. 
Memory allocations have been performed by the time an 10 
application is in an install state. A loaded application should 
also be registered. When an application is registered, it is 
selectable and it is ready to process and respond to APDU 
commands. Installation and registration may be performed 
simultaneously by the same APDU command. An applica- 15 
tion is also personalized after loading. A personalized appli- 
cation includes card holder specific data and other required 
data which allows the application to run. 

In the example shown in FIG. 13, the cryptographic key 
and MAC/Signature key are shown to be included in the 20 
functions of card domain 308/security domain 310. If a 
security domain is associated with the application being 
loaded, then the security domain will be invoked. However, 
if no security domain 310 is associated with the application 
which is being loaded, then the cryptographic key and the 25 
signature key of card domain 308 will be utilized. In contrast 
to the install commands sent to the smart card during the 
initialization phase, the post issuance install command is not 
issued in a secured environment, therefore it is preferably 
protected with a cryptographic key, such as a MAC/ 30 
Signature key. Card domain 308 manages the post-issuance 
loading of a new application, while secure domain 310 
ensures the validity and integrity of the new application once 
the new application has been loaded onto the smart card. If 
a secure domain 310 is not associated with the newly loaded 35 
application, then card domain 308 performs secure domain's 
310 functions. Once the new application is post-issuance 
downloaded, various keys, such as an cryptographic key and 
a signature key, are preferably utilized for installation and 
personalization of the application. 40 

A method and system for a smart card domain and a 
security domain has been disclosed. Software written 
according to the present invention may be stored in some 
form of computer-readable medium, such as memory or 
CD-ROM, or transmitted over a network, and executed by a 45 
processor. 

Although the present invention has been described in 
accordance with the embodiment shown, one of ordinary 
skill in the art will readily recognize that there could be 5Q 
variations to the embodiment and these variations would be 
within the spirit and scope of the present invention. 
Accordingly, many modifications may be made by one of 
ordinary skill in the art without departing from the spirit and 
scope of the appended claims. $$ 

What is claimed is: 

1. A smart card comprising: 

a card life cycle having a plurality of states; 

a memory including an indication of which of said states 
said card life cycle is in; and 60 

a card domain application including 
an issuer key associated with the issuer of said smart 
card, 

a function for managing said life cycle of said smart 
card, and 65 

a function for tracking the status of said life cycle of 
said smart card, whereby said card domain applica- 
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tion represents the interests of the issuer and man- 
ages said card life cycle. 

2. A smart card as recited in claim 1 wherein said card 
domain application further includes: 

a function for blocking said smart card. 

3. A smart card as recited in claim 1 wherein said states 
of said card life cycle include masked, initialized, load 
secured and blocked. 

4. A smart card as recited in claim 1 wherein said states 
of said card life cycle are in an irreversible sequence and 
wherein said states of said card life cycle place said smart 
card into an increasing level of security. 

5. A smart card as recited in claim 1 wherein the contents 
of said memory determines the state of said card life cycle. 

6. A method of blocking a smart card comprising: 
detecting a problem with said smart card by an application 

of said smart card; 
sending a card block request from said application to a 
card domain application of said smart card, said card 
domain application having the capability to block said 
smart card; 

determining by said card domain application whether said 

card block request is valid; and 
blocking said smart card by said card domain application, 

whereby said smart card is not operational for a user. 

7. A method as recited in claim 6 wherein said card 
domain application includes an issuer key associated with 
the issuer of said smart card, whereby said card domain 
application represents the interests of the issuer. 

8. A method of moving a smart card through a sequence 
of card life cycle states, said method comprising: 

receiving said smart card in a masked state, said masked 
state indicating that components necessary for initial- 
ization are available on said smart card; 

initializing said smart card using an initialization key; 

placing said smart card into an initialized state; 

loading an application onto said smart card post-issuance; 
and 

placing said smart card into a load secured state, whereby 
said smart card passes through a number of said states 
of said card life cycle. 

9. A method as recited in claim 8 further comprising: 
receiving a card block request; 

blocking said smart card; and 

placing said smart card into a blocked state, whereby said 
smart card is not operational for a user. 

10. A method as recited in claim 8 wherein said card life 
cycle states are managed by a card domain application. 

11. A method as recited in claim 8 wherein said states of 
said card life cycle are in an irreversible sequence. 

12. A method as recited in claim 8 wherein said states of 
said card life cycle place said smart card into an increasing 
level of security. 

13. A smart card comprising: 

a first application having a sequence of life cycle states; 
and 

a card domain application including 

an issuer key associated with the issuer of said smart 
card, 

a function for loading said application onto said smart 

card, said loading causing said first application to be 

placed into a loaded state, 
a function for installing said application on said smart 

card, said installing causing said first application to 

be placed into an installed state, and 
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a function for registering said application on said smart 
card, said registering causing said first application to 
be placed into a registered state, whereby said card 
domain application represents the interests of the 
issuer and manages said first application. 

14. A smart card as recited in claim 13 wherein said card 
domain application further includes: 

a cryptographic service for loading said first application 
onto said smart card post-issuance. 

15. A smart card as recited in claim 13 wherein said first 
application further includes: 

a function for personalizing said first application, said 
personalizing causing said first application to be placed 
into a personalized state, whereby said personalizing is 
under the authority of said first application. 

16. A smart card as recited in claim 13 wherein said first 
application further includes: 

a function for blocking said first application, said block- 
ing causing said first application to be placed into a 
blocked state, whereby said blocking is under the 
authority of said first application. 

17. A method of moving an application of smart card 
through a sequence of application life cycle states, said 
method comprising: 

receiving said application on said smart card, said receiv- 
ing placing said application into a loaded state; 

installing said application on said smart card, said install- 
ing placing said application into an installed state; 

registering said application on said smart card, said reg- 
istering placing said application into a registered state; 

personalizing said application on said smart card, said 
personalizing placing said application into a personal- 
ized state, whereby said application is available for use. 

18. A method as recited in claim 17 further comprising: 
receiving an application block request; 

blocking said application; and 



10 



15 



25 



30 



35 



placing said application into a blocked state, whereby said 
application is not available for use. 

19. A method as recited in claim 17 further comprising: 
receiving an application delete request; 

deleting said application from said smart card; and 
indicating said application is in a not available state, 
whereby said application is not available for use. 

20. A method as recited in claim 17 wherein said appli- 
cation is received by being loaded into a memory of said 
smart card during initialization of said smart card, whereby 
said application is present on said smart card before issu- 
ance. 

21. A method as recited in claim 17 wherein said appli- 
cation is received by being loaded onto said smart card 
post-issuance, whereby said application appears on said 
smart card after issuance. 

22. A method of moving an application of smart card 
through a sequence of application life cycle states after 
issuance of said smart card, said method comprising: 

issuing said smart card; 

indicating within said smart card that said application is in 
a not available state; 

loading said application onto said smart card post- 
issuance, said loading placing said application into a 
loaded state; and 

installing said application on said smart card, said install- 
ing placing said application into an installed state, 
whereby said application is available for use on said 
smart card. 

23. A method as recited in claim 22 further comprising: 
personalizing said application on said smart card, said 

personalizing placing said application into a personal- 
ized state. 
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